kernel exploit

[+] CLIQUER POUR AFFICHER

!!EXPLOIT IS FOR RESEARCH PURPOSES ONLY!!

Usage Instructions:

Compile and run the kernel module.

When the "PRESS THE BUTTON IN THE MIDDLE OF THIS" comes on, pulse the line circled in the picture low for ~40ns.
Try this multiple times, I rigged an FPGA button to send the pulse.
Sometimes it kernel panics, sometimes it lv1 panics, but sometimes you get the exploit!!
If the module exits, you are now exploited.

This adds two new HV calls,
u64 lv1_peek(16)(u64 address)
void lv1_poke(20)(u64 address, u64 data)
which allow any access to real memory.

The PS3 is hacked, its your job to figure out something useful to do with it.

http://geohotps3.blogspot.com/
~geohot

Greg59750 Wrote:Voici un nouveau billet de George Hotz

Right now, I'm playing with the isolated SPEs, trying to get metldr to load from OtherOS. Interesting thing, I am not using the exploit. I always assumed the enable isolation mode register was hypervisor privileged. It's not, it's kernel privileged, which means using hypervisor calls you can all get to it. So, get to hacking. Here is the code I am playing with.

I'm not that opposed to releasing the exploit, but I think the majority of you are going to be disappointed, even if you do get it working. Unless you have pushed the HV to it's limits, this exploit really isn't going to do much for you...yet. So install OtherOS and start playing around. If people start coming up with convincing reasons why they need the exploit to go further, I'll release it. It's just a waste to release if people can't make use of it.

As far as the GPU goes, I have full access to the GPU memory space 0x2800... But without a driver, it's useless. 3D video card drivers are notoriously hard to write, look at the ATI and NVIDIA ones for linux. The best are still the closed source manufacturer ones. I'm not even sure I believe that the HV restricts video card access, just that the OtherOS driver is 2D. If someone skilled in video card driver development comes forward, and they can explain in detail what the HV is restricting, I'll send them the exploit.

And something has to be done about the comments. Theres a couple of good ones, mixed in with tons of trash. Please, if you don't have something technical and useful to say, don't say it. This is not the place for congratulations(go back to the hello hypervisor post), debates about piracy(go somewhere else, the internet is big), or trying to convince me to do X.

Malheureusement je ne suis pas en mesure de vous faire une traduction , donc voila je fait passé l'info

Right now, I'm playing with the isolated SPEs, trying to get metldr to load from OtherOS. Interesting thing, I am not using the exploit. I always assumed the enable isolation mode register was hypervisor privileged. It's not, it's kernel privileged, which means using hypervisor calls you can all get to it. So, get to hacking. Here is the code I am playing with.

I'm not that opposed to releasing the exploit, but I think the majority of you are going to be disappointed, even if you do get it working. Unless you have pushed the HV to it's limits, this exploit really isn't going to do much for you...yet. So install OtherOS and start playing around. If people start coming up with convincing reasons why they need the exploit to go further, I'll release it. It's just a waste to release if people can't make use of it.

As far as the GPU goes, I have full access to the GPU memory space 0x2800... But without a driver, it's useless. 3D video card drivers are notoriously hard to write, look at the ATI and NVIDIA ones for linux. The best are still the closed source manufacturer ones. I'm not even sure I believe that the HV restricts video card access, just that the OtherOS driver is 2D. If someone skilled in video card driver development comes forward, and they can explain in detail what the HV is restricting, I'll send them the exploit.

And something has to be done about the comments. Theres a couple of good ones, mixed in with tons of trash. Please, if you don't have something technical and useful to say, don't say it. This is not the place for congratulations(go back to the hello hypervisor post), debates about piracy(go somewhere else, the internet is big), or trying to convince me to do X.

MoMo 6o Wrote:

OOKAMI Wrote:bon

ca a bougé coté hotz

j'ai pas encore tout lu mais le titre est super interessant puisqu'il semblerait qu'il ai acces aux SPE isolés !

affaire a suivre !

Tu a été prévenue GeoHot, on avait dit "pas un mot sur le net sinon..."


Ok je sors =>

A Level Playing Field
Right now, I'm playing with the isolated SPEs, trying to get metldr to load from OtherOS. Interesting thing, I am not using the exploit. I always assumed the enable isolation mode register was hypervisor privileged. It's not, it's kernel privileged, which means using hypervisor calls you can all get to it. So, get to hacking. Here is the code I am playing with.

I'm not that opposed to releasing the exploit, but I think the majority of you are going to be disappointed, even if you do get it working. Unless you have pushed the HV to it's limits, this exploit really isn't going to do much for you...yet. So install OtherOS and start playing around. If people start coming up with convincing reasons why they need the exploit to go further, I'll release it. It's just a waste to release if people can't make use of it.

As far as the GPU goes, I have full access to the GPU memory space 0x2800... But without a driver, it's useless. 3D video card drivers are notoriously hard to write, look at the ATI and NVIDIA ones for linux. The best are still the closed source manufacturer ones. I'm not even sure I believe that the HV restricts video card access, just that the OtherOS driver is 2D. If someone skilled in video card driver development comes forward, and they can explain in detail what the HV is restricting, I'll send them the exploit.

And something has to be done about the comments. Theres a couple of good ones, mixed in with tons of trash. Please, if you don't have something technical and useful to say, don't say it. This is not the place for congratulations(go back to the hello hypervisor post), debates about piracy(go somewhere else, the internet is big), or trying to convince me to do X.

De plus, il faut savoir que depuis le 6.00, Sony a modifié structurellement le firmware et a retiré un certain nombre de choses "inutiles" pour faire tourner les jeux mais indispensables pour lancer certains utilitaires et autres homebrews. Ceci a été pallié, en grande partie, par nos fendus du développement mais il faudrait obliger une mise à jour générale de tous ce qui existe en homebrew (jeux et utilitaires) ainsi que les thèmes et tout ce qui va avec. En effet, nous sommes arrivés avec le 6.xx à un point qui rappelle le passage des homebrews 1.xx à celui des 3.xx mais en pire. En effet, le 6.xx ne permet plus le lancement des ELF en l'état et il faut repack tous les programmes afin de les rendre compatibles avec le nouveau système de Sony[...].

Voila un message de MathieuLH sur la partie forum d'un site concurent, pour info, Mathieulh etait quelqu'un de tres présent sur la Scène psp.Il s'est aussi interressé à la ps3. Enfin cest pas un idiot il sait de quoi il parle

Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

Mathieulh Wrote:Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.